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(57) Abstract: The present invention includes a merchant system (105) that recognizes virtually any payment device (120) of tech- 
nology that uses electronic check processing as a payment mechanism. Fbr example, the merchant system (105) associates presenta- 
tion of the payment device (120) with information used to electronically debit a checking account, such as MICR data, and submits 
the same to a transaction processor (115) capable of setding electronic debit transactions. 
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ALTERNATIVE PAYMENT DEVICES USING ELECTRONIC CHECK PROCESSING AS A PAYMENT 

MECHANISM 

FIELD OF THE INVENTION 
The present invention relates to the field of electronic commercial transactions. More specifically, 
the invention relates to merchant systems designed to recognize alternative payment devices that use 
electronic check processing as a payment mechanism. 

BACKGROUND OF THE INVENTION 
Consumers and merchants in today's marketplace have access to a wide variety of technologies for 
extending credit or otherwise transfem'ng monies for goods or services ("products"). For example, consumer 
and merchants use traditional debit technologies such as paper checks. A check refers to a draft or order for 
a certain sum of money payable on demand to a certain named entity, the entity's order, or to the bearer 
thereof. Generally, the face of a check includes magnetic ink character recognition ("MICR") characters that 
can be read electronically. The MICR characters typically include a checking account number, the bank 
transit number, the check sequence number, and the like. In addition, the MICR characters may indicate 
whether the check is a company check or a personal check. The fomn or font of the MICR characters and 
their position along the bottom edge of the check are generally prescribed by standards promulgated by the 
American National Standards Institute ("ANSI"), which are incorporated by reference herein. 

Paper checks are generally processed through clearinghouse ("ACH'') networics, which can include 
some or all banks, clearinghouse corporations, the Federal Reserve bank, or the like. For example, a payor, 
or check writer, may authorize an originator, such as a grocery store, to debit the payor's checking account by 
writing a check for, for example, groceries. The originator forwards the authorization to an originating 
depository financial institution ("ODFI"), such as the grocer's bank. The ODFI sends the authorization through 
the ACM networt( to a receiving depository financial institution ("RDFr), such as the payor's bank. The RDFI 
then can transfer funds by debiting the payor's checking account and sending a credit through the ACH 
networic to the ODFI, or grocer's bank. 

To avoid many drawbacks associated with the foregoing paper check processing, such as 
processing delays measured in many days and sometimes in one or more weeks, ACH networi(S now provide 
for electronic check processing. For example, merchants can now have personal checks converted to 
electronic ACH debits, often by scanning in paper check data at the point-of-sale, and returiiing the paper 
copy of the check to the consumer. The paper check data generally includes data representing the MICR 
characters, an amount, a payee, a scan of one or both sides of the paper check, and the like. As can be 
expected, the electronic ACH debits can be processed at much greater speeds due at least in part to the lack 
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of paper handling that will occur. Moreover, some ionics are processing a da/s electronic items prior to 
processing the da/s paper items. 

The decreased processing delays associated with the electronic ACH debits often advantageously 
provide more consistent deposit patterns back to merchants and decrease the delay in discovering and 
5 stopping the use of fraudulent checics. Additionally, as discussed in the foregoing, electronic ACH debits also 
advantageously allow merchants to immediately return the paper check to the customer. 

Other technologies available to consumers and merchants in today's maricetplace include traditional 
credit and debit card technologies. While these traditional card technologies enjoy wide acceptance as a 
method of paying for products both in modem online and traditional paper processing environments, they 

10. have significant drawbaci^s for consumers and for merchants. For example, as compared with the banking 
population, a much smaller percentage of consumers have or use one or more credit or debit cards. 
Moreover, the Issuer of card technologies often charges high interest rates to the consumer, while also 
charging high fixed or high variable processing fees to merchants. The high rates often render smaller 
incremental charges via traditional card technotogies impractfcal. Also, more and more consumers are unable 

1 5 or unwilling to pay down their debt, so they resort to revolving that debt from one credit card to the next In 
addition to the foregoing, traditional card technologies can be subject to fraud, fines, or the like. 

Still other technologies available today include modem payment technotogies. sudi as. convenience 
or loyalty cards, radto frequency payment devfces such as Easypay, Speedpass. Fastpay, toll road 
transpondere, or the like. Generally, a consumer first enrolls in a payment technology with a merchant or a 

20 gatevray service. During enrollment, the consumer often provWes a credit or debit cad account from whfch 
debits will be made. The merchant then issues, for example, the payment device to the consumer. When the 
consumer desires to purchase products from the merchant, the consumer presents the payment device to, for 
example, a receiver device designed to communicate with the payment device so as to uniquely identify the 
consumer's associated credit or debit card account The merchant then bills the consumer's card for the 

25 purchase of the products. 

The foregoing payment technologies are finding wider acceptance among consumers as the 
payment technologtes often provide a very convenient payment mechanism, and are finding wider acceptance 
among merchants as payment technologies often generate consumer loyalty. However, because the 
foregoing payment technologies often emptoy traditional card technologies as the backend payment 

30 mechanism, these payment technologies unfortunately assume many or all of the foregoing drawbacks 
associated virith the traditional card technokjgies, including, for example, the inability to practfcally sen/fce 
smaller, incremental-type charges. 
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SUMMARY OF THE INVENTION 
Based at least in part on the foregoing drawbacks, a need exists for transaction processing system 
that allows consumers to use modem payment technologies without incorporating the drawbacks of traditional 
credit or debit card technologies. One embodiment of the invention includes a transaction processing system 
5 that converts a transaction produced from virtually any payment device or technology, into electronic debits 
processed through clearinghouse systems as traditional electronic ACfH debits to a checking account. Thus, 
the. transaction processing system advantageously avoids the negative drawbacks of traditional credit or debit 
card technologies while incorporating the advantages pf electronic ACH debit processing. Moreover, by using 
a checking account for ttie debit, tiie transaction processing system advantageously uses the most prevalent 
10 financial account found in the U.S. population. According to some embodiments, the transaction processing 
system also provides for the guarantee of payment to tiie merchant or retailer Initiating the transactions. 

According to one embodiment, the transaction processing system includes a merchant system, a 
transaction processor, an automated clearinghouse system and a user account. The transaction processor 
accepts enrollment transaction requests from merchant systems seeking to issue a payment device to a new 
15 user, where tiie payment device is other than apaper check and designed to access debit funds in the user's 
checking account For example, tfie payment device can include cards, transponders, biometric elements, or 
the like. During enrollment processing, ttie ti^nsaction processor accepts user data, MICR data^ the check 
number, and tiie like. The transaction processor also accepts a transaction date and merchant data, such as 
a merchant's identification number or ottier data. 
20 According to one embodiment, tiie transaction processor processes enrollment transaction requests 

by validating some or all of tiie user data, by clearing some or all of tiie user data ttirough negative and/or 
positive databases, assessing a risk score to the enrollment fa^nsaction using, for example, a variety of payor 
historical payment variables as well as variables associated witti typical transactions in that standard industry 
code (SIC - a four digit code often used to denote differing specific industiies), validating MICR data through 
25 ACH processing, or the like. The transaction processor retums a result of tiie enrollment transaction to tiie 
merchant. According to one embodiment, the result can include advice on whettier to an accept or decline 
tiie user, an assessed risk score associated witii enrolling the user, a result of a negative and/or positive 
database search, some or all of the same, or tiie like. 

According to anotiier embodiment, the transaction processor also accepts purchase transaction . 
30 requests from merchant systems tfiat have recognized a payment device presented by a user as payment for 
a product. For example, the merchant system can associate a presented payment device wifli a unique user 
account directing tiie merchant to wittidraw funds to cover payment from tiie user's checking account. The 
merchant system organizes the information into a purchase ti^nsaction request and fbn/vards tiie same to flie 
transaction processor. During tiie processing of purchase transactions, tiie tiansaction processor accepts 
35 data, such as some or all of tiie foregoing user data, some or all of the foregoing MICR data, some or all of 
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the foregoing merchant data, or the like. The transaction processor also accepts specific transaction data 
such as the date, time or amount of the transaction, the product information involved in the transaction, and 
the like. The transaction processor also submits one or more electronic ACH debits representing the 
transaction to the clearinghouse system. 
5 Moreover, In an embodiment, the transactton processor processes purchase transaction requests by 

vacating some or all of the submitted user data, by clearing some or ail of the user data through negative 
and/or positive databases, by assessing a risk score to the enrollment transaction, by settling the transaction 
through electronic ACH debit processing, and the like. The transaction processor returns an authorization 
result of the payment transaction to the merchant. For example, the result can Include advice on whether to 
10 accept or decline the purchase transaction based on an assessed risk score associated with transaction, a 
result of a negative and/or positive database search, some or all of the same, or the like. 

In one embodiment, the merchant may manage the payment device, such as a proprietary loyalty 
caid, thereby allowing the users to purchase products at ttie merchant's retail locations using the payment 
device. Addittonally, according to at least one embodiment, a "gatevray" can act as an aggregator of services 
1 5 and provide multiple merchants with the ability to allow payment through the gateway's payment device. For 
example, the gatevi^y may altow users to purchase products at. for example, many differing merchants' retail 
locatk>ns using 0ie same payment device. 

For purposes of summarizing the invention, certain aspects, advantages and novel features of the 
invention have been described herein. It is to be understood that not necessarily all such advantages may be 
20 achieved in accordance with any particular embodiment of ttie inventfon. Thus, the invention may be 
embodied or carried out in a manner that achieves or optimizes one advantage or group of advantages as 
taught herein without necessarily achieving other advantages as may be taught or suggested herein. 

BRIEF DESCRIPTION OF THE DRAWINGS 
A general architecture that implements the various features of the invention will now be described with 
reference to the drawings. The drawings and the associated descriptions are provided to Illustrate 
embodiments of the invention and not to limit the scope of the invention. Throughout the drawings, reference 
numbers are re-used to indicate conespondence between referenced elements. In addition, the first digit of 
each reference number Indicates the figure in which the element first appears. 

FIGURE 1 illustrates a diagrammatk: representation of an exemplary transaction processing system 
whfeh altovKs a user to present payment technotogies other than checks or credit cards and have payment 
extracted from a debit account, acconJing to an embodiment of ttie invention. 

FIGURE 2 illustrates an exemplary webpage used to enroll the user in the transactton processing 

system of FIGURE 1, according to an embodiment of the invention. 

FIGURE 3 illustrates an enrollment process, according to an embodiment of the Invention. 

-4- 



25 



30 



35 



wo 03/083751 



PCT/US03/06581 



FIGURE 4 illustrates a purchase process, according to an embodiment of the invention. 

FIGURE 5 illustrates a transaction processing process, according to an embodiment of the invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
5 A transaction processing system converts the presentation of virtually any payment device or 

technology, into electronic debits to a checking account processed through a clearinghouse system. Thus, 
the transaction processing system advantageously avoids the negative drawbacks of traditional credit or debit 
card technologies while incorporating the advantages of electronic debit processing. Moreover, by using a 
checking account, the transaction processing system uses the most prevalent financial account found in the 
10 banking population. 

As will be apparent, many of the disclosed features may be used without others, and may be 
implemented differently than described herein. Further, although described primarily in the context of a 
transponder based system, the various inventive features are also applicable to types of alternative payment 
. devices other than paper checks or credit or debit cards, including, but not limited to loyalty cards, electronic 
IS wallets, one or more smart cards, one or more biometric elements such as a thumbprint or facial recognition, 
other point-of-sale payment devices, or the like. The following description is thus intended to illustrate, and 
not limit, the invention. 

According to one embodiment, the transaction processing system includes a merchant system, a 
transaction processor, a user payment device, a clearinghouse system, and a user debit accourit The 

20 transaction processor accepts enrollment transaction requests from merchant systen)s seeking to issue a 
payment device to a new user, such as a potential payor, where the payment device is other than a paper 
check and designed to access debit funds in the user's debit account, such as a checking account. For 
example, the user can include an individual consumer attempting to make a financial transaction. The 
payment device can comprise a convenience or loyalty card, a transponder, such as radio or other frequency 

25 transponder, an electronic wallet, one or more smart cards, one or more biometric elements such as a 
thumbprint or facial recognition, other point-of-sale payment devices, or the like. During enrollment 
processing, the transaction processor accepts user data, such as driver's license number or other 
identification infonDation, demographic infonmation such as name, address, birth date, telephone number, 
social security number, or the like, one or more biometric measurements, passwords, or the like. The 

30 transaction processor also accepts MICR data such as scanned or manually entered MICR characters fifom 
an unused paper check of the user, the check number, or the like. The transaction processor also accepts a 
transaction time, place and date, and merchant data, such as a merchant's identification number, location, or 
otherdata. 

35 ENROLLMENT TRANSACTIONS , 

'5- 
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According to one embodiment the transaction processor processes enrollment transaction requests 
depending upon services generally chosen by the submitting merchant. For example, a merchant may chose 
to have some or all of the user data validated. According to one embodiment the transaction processor can 
detemnine whether user data, such as, for example, driver's license infomiation, driver's license infomiation, 
MICR data, or the like match those contained in one or more databases accessible to the transaction 
processor. For example, the transaction processor may access a wide number of sources, including credit 
agencies, online infonnation or databases, public records, or the like. According to one embodiment some or 
all of the user data, social security number, MICR data, or the like is provided by the user during enrollment 

According to one embodiment, a merchant may also choose to have the transaction processor clear 
some or ail of the user data through negative and/or positive databases. For example^ the transaction 
processor can compare the user's name, driver's license infonnation, or other demographic infonnation to a 
database of known high risk (negative databases) or known low risk (positive databases) data. When a 
match is found in ttie negative databases and tiie merchant desires that 0ie transaction processor guarantee 
future ti^nsactions associated witti ttie enrolling user, ttie transaction processor may infonm tiie merchant 
system to decline enrollment to the user. AKemativeiy, when the processor is hot acta'ng as a guarantor, flie 
transaction processor may return infonnation infbmiing ttie merchant of, for example, a negative database 
match. 

A merchant may also choose to have the transaction processor assess a risk score for the 
enrollment transaction. As in known in the art, assessing a risk score can advantageously include predictive 
nrxxleling systems ttiat analyze a plurality of relevant variables in order to detemnine ttie probability of a 
particular transaction being good or bad. such as tiie probability the transaction will or will not clear the 
banking system via clearinghouse processing. 

Credit risk scoring algorittims generally take into account those pieces of available data ttiat have 
been detemiined to be statistically significant. The risk score may be a nomnalized value ttiat indicates the 
probability ttiat the transaction will be good. If the merchant desires tiiat tiie transaction processor guarantee 
future transactions associated with the enrolling user as well as process ttie transaction, ttie transaction 
processor may simply advise the merchant whetiier to decline enrollment to ttie user based on, for example, 
whettier ttie risk score meets a predetennined ttireshold. AKemativeiy, if ttie ttansaction processor Is not 
acting as a guarantor, ttie transaction processor may compare a merchants 'score card," which includes 
predetennined values below which ttie merchant and/or ttie processor agree, ttie risk of loss is acceptable to 
ttie merchant OttienArise, tiie transaction processor may simply return tfie risk score to ttie merchant system. 
Alttiough risk scoring algorittims are known in general, it will be appreciated ttiat the details of most 
algorithms, including the specific data considered and the weight given various date, are considered 
proprietary by their owners. 
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The merchant may also choose to have the transaction processor validate any ACH processing data: 
According to one embodiment the transaction processor can perfonn a validation transaction where a user's 
checking account is debited and credited for, for example, an equal amount. The result of such debiting and 
crediting can be reported through, for example, settlement files similar to those to be discussed with reference 
S to purchase transactions. The foregoing validation transactions ensure that the user's account and the 
associated banking institutions are compatible with the processing of electronic ACH debits. 

PURCHASE TfRANSACTIONS 

According to another embodiment, the transaction processor also accepts purchase transaction 
10 requests from merchant systems that have recognized a payment device presented by a user as payment for 
a product. The merchant system associates the device with a unique account directing the merchant to 
withdraw funds to cover payment from the user's debit account. During purchase processing, the transaction 
processor accepts data, such as some or all of the foregoing user data, some or all of the foregoing MICR 
data, some or all of the foregoing merchant data, or the like. The transaction processor also accepts data 

1 5 related to the specific transaction, such as product information, amount of purchase, time of day, day of week, 
date, location of purchase, purchaser, cash back amount, type of payment device, and the like. The 
transaction processor also organizes and submits one or more electronic ACH debits associated with the 
transaction to the clearinghouse system. 

Moreover, in an embodiment similar to that disclosed with reference to enrollment transaction 

20 requests, the transaction prxessor processes transaction requests by validating some or all of the submitted 
user data, by clearing some or all of the user data through negative and/or positive databases, by assessing a 
risk score to the enrollment transaction, by settlement through electronic ACH debit processing, or the like. 
The transaction processor retums an authorization result of the purchase transaction, to the merchant. As 
disclosed in the foregoing, the fomiat and content of various infomiation within the authorization result may 

25 depend on whether the transaction processor will act as a guarantor for the payment transaction. As 
disclosed, the authorization result can include advice or instaictions on whether to an accept or decline the 
purchase transaction, a risk score to inform the merchant of a risk associated with accepting the transaction, a 
result of a negative and/or database search, or the like. 

When the transaction processor processes purchase transaction requests that include settlement, 

30 the transaction processor can send a report, often in the fonn of a settlement file, to the merchant For 
example, when the transaction processor processes one or more (e.g., a batch oQ transactions, the 
transaction processor may send a preliminary settlement report which is often subject to reversal. Similar to 
paper check processing, electronic check processing often assumes that transactions are settled, but then 
reverses a transaction when debits and/or credits fail during processing by a clearinghouse system, such as 

35 the ACH. The foregoing settlement file may be sent after one or more transactions have been processed, one 
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or more batches of transactions have been processed, one or more transaction or batches of transactions 
have been processed for a given merchant some time delay after processing, or the like. Moreover, the 
settlement file may be sent at intervals of time, at the end of each day, week, or the like. An artisan will 
recognize from the disclosure herein, that when the transaction processor acts as a guarantor for a 
5 transactk3n, the data related to that transaction in the settlement file is often then not subject to reversal 
because the risk of a failed settlement has been transfened to the transaction processor. 

Thus, the foregoing transaction processing system advantageously allows the association of a 
merchanf s payment device to a user's checking account. The transaction processing system provides for 
enrollment of the user and the processing of purchase transactions. During enrollment and purchase 

1 0 transaction request processing, the transaction processor can perfomi various services, often chosen through 
preexisting agreements with merchants, such as user data validation, negative and positive database 
searching, risk assessments, validation or settlement processing, or the like. 

To facilitate a complete understanding of the invention, the remainder of the detailed description 
describes the invention with reference to the drawings, wherein like reference numbers are referenced with 

15 like nunfierals throughout. 

FIGURE 1 illustrates a diagrammatic representation of an exemplary embodiment of a transaction 
processing system 100 which processes transactions for merchants associated with payment technologies 
that debit funds of, for example, a user's checking account. As shown in FIGURE 1, the transaction 
processing system 100 includes a merchant system 105 designed to communicate with a user enrollment 

20 system 110, a transaction processor 115, and a user payment device 120. FIGURE 1 also shows the 
transaction processor 115 communicating with a clearinghouse system 125. According to one embodiment, 
at least the merchant system 105, the user enrollment system 110, the transaction processor 115, and the 
clearinghouse system 125 communicate with one another through one or more communication links. 

As disclosed in the foregoing, the user enrollment system 110 communicates with the merchant 

25 system 105 to enroll users into modem payment technologies. The modem payment technologies avoid the 
drawbacks of traditional credit or debit card technologies by associating a debit account 130, such as a 
checking account with the user payment device 120. .During enrollment the user uses the enrollment system 
110 to submit various infomiation to the merchant system 105. The merchant system 105 organizes the 
information into an enrollment transaction request and submits the enrollment transaction request to the 

30 transaction processor 115. The transaction processor 115 perfonns various merchant-selected sendees, 
such as those disclosed in the foregoing, and retums an enrollment result to the merchant system 105. 
Depending upon the enrollment result the merchant system 105 may enroll the user by issuing to the user the 
user payment device 1 20 and associating the device to, for example, that user's debit account 1 30. 

When the user desires to make a purchase from the merchant the user presents the user payment 

35 device 120, and the merchant system 105 uniquely identifies the debit account 130. The merchant system 
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105 submits a purchase transaction request and submits the purchase transaction request to the transaction 
processor 115. The transaction processor 115 perfomis various merchant-selected services, such as those 
disclosed in the foregoing, and returns an authorization result to the merchant system 105. Depending upon 
the authorization result, the merchant system 105 may complete the purchase by providing the products to 
the user and infomiing the transaction processor 115 of the same. The transaction processor 115 then 
advantageously perfomis settlement through the issuance of one or more electronic ACH debit transactions to 
the clearinghouse system 125. thereby transfemng funds from the debit account 130 to a credited account 
.135, such as, for example, the merchant's bank account 

According to embodiments where the user payment device 120 communicates through, for example, 
a wireless signal, the merchant system 105 may include a merchant receiver 140 designed to receive the 
foregoing communications. 

MERCHANT SYSTEM 105 

According to one embodiment, the merchant system 105 includes the components be used to 
implement a system which uniquely identifies a debit account when a user presents payment devices other 
than paper checks or credit cards. For example, the merchant system 105 may include one or more central 
server systems 142. which can communicate with one or more merchant receivers 140, one or more user 
account databases 144 and with electronic documents 146. The user account databases 144 can store 
various user data including MICR data which can be used to identify the debit account 130, and the 
associated device identifier ("ID") the merchant system 105 will use to recognize the user payment device 
120. For example, as described in the foregoing with respect to enrollment, the user can provide MICR data 
from a check that conesponds to the account from which funds are to be drawn, such as, for example, the 
debit account 130. The MICR data can include a routing or bank transit number, generally identifying the 
financial institution or groups of financial institutions that issued the original user's check, an account number 
against which the original check is drawn, a check sequence number, various separator symbols often unique 
to the financial institution, and the like. In addition, the MICR data can indicate whether the check is a 
company check or a personal check. The device ID can include an identification number or account number 
which uniquely identifies each user's debit account 130. which may also be used by the server 142 to index 
other data in the user account databases 144. 

The user account database 144 may also; include user enrollment data, such as the name, email, 
address, login identifier, password, or the like of each user. The infonnation may also include historical data 
fore each user, such as transactions, purchases, payments, risk scores, credit histories or other financial 
infonnation, public record data, or the like. 
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AKhough the usisr account database 144 is disclosed with reference to one embodiment, a skilled 
artisan will recognize from the disclosure herein that the database can be one or more remote or local 
database systems, or the like. 

In an embodiment where the enrollment system 1 10 includes the use of a computer network, such as 
5 the Internet, the sender 142 can also include a web server accessing the electronic documents 146. The 
iserver 142 generally processes requests for the documents 146, retrieves the documents 146. perfonns any 
necessary processing, and sends the documents 146 to the requesting computer system via the computer 
network. The documents 146 can be used to generate the electronic enrollment pages, user pages helpful in 
managing user accounts, or the like. Moreover, the documents 146 can be used to generate a variety of 
10 pages, such as search and other navigational pages, login, authentication, and authorization pages, online 
stores, and so forth. 

Although the merchant system 105 is disclosed with reference to one embodiment of Internet 

enrollment, the invention is not Intended to be limited thereby. Rather, an artisan will recognize from the 

disclosure herein a wide number of alternative systems providing user enrollment, such as. for example, user 
15 enrollment via the mail, a telephone call, a facsimile, or the like. Often, the enrollment vehicle options are 

limited by rules of the financial institutions governing portions of the transaction, such as, for example, mles 

generated by the National Automated Clearing House Association ("NACHA') or by the national ACH networi(. 

Additional infonmation on the processes employed by the ACH, mles of the NACHA. the process of clearing 

paper checks and applying predictive scoring algorithms for risk assessment, can be found in U*S. Pat. No. 
20 5,679.940, issued to Templeton et al. on October 21. 1997. entitled 'Transaction System With On/Off Una 

Risk Assessment,'' which is incorporated herein by reference, and is generally considered with the scope of 

knowledge possessed by one of onJinary skill in the banking community. 

In addition, the merchant system 105 can include or comprise any device that interacts with or 

provides data to the merchant receiver 140, the user enrollment system 110, or the transaction processor 
25 115, including by way of example, any Internet site, private networtcs, networi^ senders, video delivery 

systems, audio-visual media providers, television programming providers, telephone switching networics, teller 

networics, wireless communication centers or the like. 

Moreover, the merchant system 105 may include one or more satellite or store computer systems 

throughout a geographically diverse networic. Each store system may be located within proximity to a 
30 merchant receiver, and may advantageously communicate with one or more servers or the sen/er system 142 

to access user Infomnation stored in one or moro database collections, such as. for example, the user account 

database 144. 
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USER ENROLLMENT SYSTEM 110 

FIGURE 1 also shows the transaction processing system 100 comprising the user enroilment system 
110. According to one embodiment, the user enroilment system 110 comprises one or more computer 
systems allowing a user to interact with the merchant system 105 via a communication link. In one 
5 embodiment, the computer is equipped with a modem or other communication device configured to 
communicate with aspects of the merchant system.105. The computer may comprise, by way of example, 
processors, program logic, or other substrate configurations representing data and instnictions, which operate 
as described herein. In other embodiments, the processors can comprise controller circuitry, processor 
circuitry, processors, general purpose single-chip or multi-chip microprocessors, digital signal processors, 
10 embedded microprocessors, microcontrollers and the like. In addition, the user enrollment system 110 can 
comprise a computer woricstation, a local area networic of individual computers, a kiosk, a point-of-sale 
device, a personal digital assistant, an interactive wireless communications device, an interactive television, a 
transponder, or the like. 

In one embodiment, the user employs the user enrollment system 110 to enroll with the merchant 
IS s^tem 105. For example, the merchant system 105 may advantageously present an electronic enrollment 
form to the user through the user enrollment system 110. The enrollment fonn can include an entry for data 
associated with the debit account the user wishes to tie to the payment device 120, such as, for example, 
MICR data from an unused check. According to one embodiment, the eri'rollment fonn may also include an 
explicit authorization from the user, authorizing the merchant, the processor, or both, to generate electronic 
. 20 debits and credits from a selected user debit account. 

When the user has completed the enrollment fonn, the user enrollment system 110 transfers the 
entered infomriation to the merchant system 105, where it is stored, for example, in the user account database 
144. An exemplary enrollment process is disclosed with reference to FIGURE 3. 

Although the enrollment system 110 is disclosed with reference to an embodiment of Internet 
.25 enrollment, the invention is not intended to be limited thereby. Rather, as disclosed, a wide number of 
altemative systems can provide user enraliment, such as. for example, user enrollment via the mail, a 
telephone call, a facsimile, or the like. Often, the enrollment vehicle options are limited by mies of the 
financial institutions goveming portions of the transaction, such as, for example, rules generated by NACHA 
for the national ACH networic. 
30 FIGURE 1 also shows the merchant system 105 including server code 148. The sender code 148 

advantageously includes one or more software processes or program logic designed to execute on the server 
systems 142. In one embodiment, the sender code 148 may advantageously include software or hardware 
components such as software object-oriented components, class components and task components, 
processes methods, functions, attributes, procedures, subroutines, segments of program code, drivers, 
35 finnware, microcode, circuitry, data, databases, data stiuctures, tables, arrays, and variables. As illustrated in 
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FIGURE 1, the server code includes enrollment process code for enrolling users into the transaction 
processing system 100, and purchase process code for allowing users to purchase products by presenting 
their user payment devices 120. 

5 TRANSACTION PROCESSOR 115 

According to one embodiment, the transaction processor 1 1 5 comprises one or more server systems 
152 communicating with one or more database collections to detennine whether to authorize particular 
transactions presented by the merchant system 105. The database collection can comprise one or more 
logical and/or physical data storage systems for storing the data used by the transaction processor 115, and 

10 may comprise two or more separate databases and/br storage systems or networics of storage systems. 

As shown in FIGURE 1 , the database collection comprises a historical transaction database 1 54. arid 
a MICR line conversion database 156. The historical transaction database 154 advantageously stores 
infonnatlon about the users' financial history, and may include transaction data from transactions processed 
by the transaction processor 115, other systems, credit reporting companies, or other commercially available 

1 5 databases. The historical transaction database 154 can Include information from, for example, credit reports, 
online activities by the user, other user data, or the like. The historical transaction database 154 can 
comprise multiple databases, such as, for example, a positive database storing positive usk infonmafion, and 
negative databases storing high-risk infomiation or names of ottienvise unqualified individuals. 

The MICR line conversion database 156 includes infomnation regarding the fonnatting of transactions 

20 submitted to the clearinghouse system 125. For example, the MICR line conversion database 156 can 
include historical and other infomiation regarding ttie placement and use of differing MICR character by 
various banking institutions or check printing companies, thereby providing the transaction processor 1 15 witti 
conversion infomfiation for converting the user entered checking account data, such as ttie MICR line, into, for 
example, electronic ACH debit or credit transactions. The MICR data and/or historical data stored in ttie 

25 MICR line conversion database 154 can also include routing numbers, account or check number, payable 
through credit institutions, traditionally absent numbers, or tfie like. 

FIGURE 1 also shows ttie transaction processor 115 including server code 158. The server code 
158 advantageously includes one or more software processes or program logic designed to execute on the 
server systems 152. In one embodiment, ttie server code 158 may advantageously include software or 

30 hardware components such as software object-oriented components, class components and task 
components, processes mettiods, functions, attributes, procedures, subroutines, segments of program code, 
drivers, firmware, microcode, circuitry, data, databases, data stnictures. tables, anrays. and variables. 

As shown in FIGURE 1. ttie server code 158 Includes transaction process code, and enrollment and 
purchase processing code. The tiransaction process code advantageously perfonris various merchant 

35 selected services, such as, for example, user data validation, negative and/or positive database searching. 
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risk scoring, account information validation, settlement processing, or the like. The transaction process code 
also retums enrollment and authorization results. As disclosed, various infonnation within the authorization 
result may depend on whether the transaction processor will act as a guarantor for the payment transaction. 
As disclosed, the authorization result can include advice or instructions on whether to an accept or decline the 
payment transaction, a risk score to infomi the merchant of a risk associated with accepting the transaction, a 
result of a negative and/or database search, or the like. 

USER PAYMENT DEVICE 120 

As disclosed in the foregoing, the user payment device 120 allows users to make purchases by 
presenting the device 120 to the merchant system 105. and having the appropriate funds withdrawn from the 
debit account 130. According to one embodiment, the user payment device 120 can comprise a wide variety 
of point-of-sale payment devices. For example, the user payment device 120 can comprise radio or other 
frequency transponders, such as toll transponders designed to automatically communicate with tollbooths, 
thereby avoiding the need to stop and pay cash to use a toll road. The user payment device 120 may 
comprise transponders designed to communicate with gas stations for the payment of fuel at the pump. 
Transponders may be used to conveniently pay for drive through services, grocer checkout counters, or 
virtually any place where payment through a wireless device makes for convenient, efficient, purch^es. 
According to one embodiment, the user payment device 120 can comprise a computing device, a personal 
digital assistant, a wireless telephone or the like. Moreover, according to one embodiment the user payment 
device 120 transmits various data when it detects the presence of a receiver for the same. Other 
embodiments may include the ability to receive data from or othenvise communicate with, for example, the 
merchant system 105. 

According to another embodiment, the user payment device 120 may comprise loyalty cards such as 
those used by many grocers, or the like. In such embodiments, the user payment device 120 may include a 
magneto stripe and/or number designed to uniquely identify the debit account 130. According to yet another 
embodiment, the user payment device 120 mdy comprise biometric solutions such as those used by quick 
serve restaurants including thumbprints, facial recognition, or the like. Other embodiments include electronic 
wallets, one or more smart cards, or the jike. 

As disclosed in the foregoing, the user payment device 120 can advantageously be associated with 
the merchant, and therefore, can often generate loyalty in customers as they desire to use their device 
instead of carrying cash or using expensive credit card technologies. 

CLEARING HOUSE NETWORK 125 

According to one embodiment, the clearinghouse system 125 comprises the national ACH networic. 
Generally, the ACH networi^ can accept electronic ACH debit and credit transactions against, for example, the 
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user's debit account 130. When the transaction processor 115 settles a transaction between the user and the 
merchant the transaction processor 115 advantageously fonnats at least one electronic ACH debit 
transaction debiting the user's debit account 130, and crediting the credited account 135. The foregoing 
electronic ACH debit and credit transactions are then transfened into the national ACH network as electronic 
5 transactions. Rules for the fonnat and content of the electronic ACH debit and credit transactions are 
governed by NACHA and considered within the scope of knowledge for an artisan within the electronic 
banking industry. 

Although the clearinghouse system 125 is disclosed with reference to this embodiment the invention 
is not intended to be limited thereby. Rather, a skilled artisan will recognize from the disclosure herein a wide 
10 number of alternatives for the clearinghouse system 125. For example, the clearinghouse system 125 may 
comprise one or more private institutions that have developed a networi^ for clearing electronic transactions 
between users thereof. Such private systems generally promulgate ailes governing the type and content of 
electronic transaction submissions. 

15 MERCHANT RECEIVER 140 

FIGURE 1 also shows the transaction processing system 100 including the merchant receiver 140. 
The merchant receiver 140 communicates with, or receives the transmission from, the user payment device 
120. The merchant receiver 140 may be a toll receiver designed to automatically read a toll transponder of a 
motorist may be a receiver designed to read a transponder waved in front ot for example, a fuel pump, or the 
20 like. According to one embodiment the receiver 140 communicates with the merchant system 105 to 
uniquely identify the user, the user's checking account data, biometric readers or scanners, or the like. 

Other embodiments may include a magnetic stripe reader or other system designed to read the 
infomnation found on loyalty cards or the like. 

COIVIMUNICATION LINKS 

FIGURE 1 also illustrates various components communicating with one another through 
communication links. In one embodiment, the communications links include portions of the Intemet which is 
a gtobal networic of computers. In other embodiments, the communications links may be any communication 
system incKiding by way of example, telephone networics, wireless data transmission systems, two-way cable 
systems, computer networics, interactive kiosk networics, automatic teller machine networics, interactive 
television networks, and tfie like. 

Based on the foregoing disclosure, the transaction processing system 100 advantegeously provides 
users with the convenience of using the payment devices 120 instead of canying cash or using expensive 
traditional card technologies. Moreover, the transaction processing system 100 advantageously provides 
merchants with the ability to select from many risk detennining or risic guarantee services, while also allowing 
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for automated processing through the clearinghouse system 125, which is generally significantly less 
expensive than the minimum fixed cost fees associated with the traditional card technologies. 

Although the transaction processing system 100 has been disclosed with respect to various 
preferred and altemative embodiments, an artisan will recognize from the disclosure herein that a wide 
number of differing devices can accomplish the functionality disclosed. For example, the merchant system 
105 and the transaction processor 1 15 may advantageously be governed by, and/or comprise a single entity 
or system. Moreover, layered gateway systems may offer users the ability to use the gateway's payment 
device In multiple retail locations of multiple merchants, without departing from the scope of the present 
disclosure. 

EXEMPLARY ENROLLMENT FORM 

FIGURE 2 illustrates an exemplary webpage 200, which can be used to enroll the user into the 
transaction processing system 100, according to an embodiment of the invention. As shown in FIGURE 2, 
the webpage 200 comprises user demographic infomiation 205, such as name, address, email, age, social 
security number, gender, or other historical or demographic information desired by the merchant or processor 
to, among other things, develop accurate risk assessments of the user. The webpage 200 also includes an 
account selection button 210, providing the user the ability to associate, for example, payments from the user 
device 120, to the debit account 130. According to one embodiment, the user can select his or her checking 
account According to other embodiments, the user may select a credit card or other financial accounts. 

When the user desires to tie his or her payment device 120 to the debit account 130, the webpage 
200 also includes an entry section for entry of debit account data 215. As shown in FIGURE 2, the debit 
account data 215 can include MICR data from an unused check. According to one embodiment, the user may 
be prompted to enter an asterisk (*). or other placeholder character, in place of the non-numeric symbols that 
are included in many MICR characters printed on a check. Alternatively, the webpage 200 may include an 
interactive portion which allows users to select from a given set of non-numeric MICR symbols to be added to 
their MICR data. Other embodiments may include instmctions on how to create and/or attach a scanned 
image of an unused check, or a file containing data from a MICR line optical and/or magnetic reader. In such 
embodiments, the merchant or the processor may incorporate hardware and/or software components 
designed to interact with such data to extract the MICR data, such as, for example, optical character 
recognition ("OCR") software, or the like. As shown in FIGURE 2. the webpage 200 may request MICR data 
be entered twice, thereby advantageously allowing the merchant system 105 to compare each entry so as to 
ensure connect entry thereof. 

Embodiments of the enrollment webpage 200 also include an authorization section 220. where the 
user explicitly authorizes the merchant system 105 and/or the transaction processor 1 15 to perfonn electronic 
ACH debit and credit transactions to his or her selected debit account Such authorization may include a 
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separate button indicating the user has read and understands the samei may have limltatidns such as a ''not 
to exceed' limitation, or the lilce. In addition, the webpage 200 includes a submit button 225. which transfers 
the user-entered data from the user enrollment system 1 10 to the merchant system 105. 

Although the webpage 200 is disclosed with reference to an exemplary embodiment, an artisan will 
5 understand from the disclosure herein that the webpage 200 may include a wide variety of interactive buttons, 
fonfns, updated electronic pages, menu selections, multimedia explanations or other presentations, or the like. 
Moreover, the webpage 200 may request that the user upload a digital picture or scanned Image of the user 
or various user documents/such as a driver's license, social security card, govemment ID, or the like. In 
addition, the webpage may include one or more printable fomfis which a user can email, mail or fax to the 
10 merchant system 105. 

As disclosed in the foregoing, the transaction processing system 100 can include a wide variety of 
other enrollment mechanisms, and the exemplary online enrollment forni 200 is not meant to limit the scope of 
the disclosure. 

15 ENROLLMENT PROCESS 300 

FIGURE 3 illustrates an enrollment process 300. according to an embodiment of the inventton. As 
shown in FIGURE 3, the enrollment process 300 generally includes the user transferring various demography 
and account data to the merchant system 105, which in one embodiment, fonnats an enrollment transaction 
request to be processed by the transaction processor 115. 

20 The exemplary enrollment process 300 begins at BLOCK 305, where the user enters the user data 

Into the enrollment system 110. As described in the foregoing, the user data can include a user name, 
address, social security number, email, govemment identification, corporate identification logins, passwords, 
biometric data such as a fingerprints or facial scans, driver's license infomiation such as license number or 
the like, scans of some or ail of the foregoing documents, outputs from magnetic stripe or other card readers, 

25 or other data helpful in assessing a risk associated with enrolling the user in the transaction processing 
system 100. 

At BLOCK 310, the user enters MICR data from one of his or her checks associated with the debit 
account 130 from which funds can be drawn. As described in the foregoing, the MICR data can include MICR 
characters, such as an account number, the bank transit number, the check sequence number, type of check, 
30 and the like. According to embodiments disclosed in the foregoing, the MICR data may also include 
placement holder characters in place of the non-numeric symbols that aro included in their MICR line, or the 
like. According to one embodiment, the MICR data read by a scanning or reading device and entered into the 
enrollment system 110. 

At BLOCK 315. the user authorizes the merchant system 105 and the transaction processor 115 to 
35 submit electronic ACH debits against the debit account 130 when the user presents the user payment device 
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120 as payment for products. As disclosed in the foregoing, such authorization can be governed by niles 
promulgated by the clearinghouse system 125. 

At BLOCK 320, the merchant system 105 organizes various user-submittecj infonfnatlon into an 
enrollment transaction request, and submits the same to the transaction processor 115. The form and fonnat 
of the enrollment transaction request can be designated or defined by the merchant system 105 and/or 
transaction processor 115, and according to one embodiment, can include infomnation identifying the 
merchant, identifying the user, date and time infomiation, infomiation designating the user's account data, 
such as MICR data, merchant infomiation, or the like. The enrollment transaction request may also include 
additional information useful in assessing the risk of the user, such as, for example, a driver's license or social 
security number, address, credit card data, or other demographic or financial data. 

After the transaction processor 115 processes the enrollment transaction, such as, for example, 
according to various disclosed merchant-selected services, the transaction processor returns an enrollment 
result. According to embodiments disclosed herein, the enrollment result provides an indication to the 
merchant system 110 of the risk associated with accepting the enrollment of the user in the transaction 
processing system 100. 

At BLOCK 325, the merchant system 105 confimis the receipt of that result, and can further instruct 
the transaction processor 1 15 to validate the enrolling user's account infomnation. For example, the merchant 
system 105 may desire to ensure that the banks, financial institutions, or the like, associated with the debit 
account 130, support the submission of electronic ACH debit transactions. According to one embodiment, the 
merchant system 105 instructs the transaction processor 115 to fomiat and submit an electronic ACH debit 
and credit for equal amounts against the debit account 130, thereby validating that the account information 
supports electronic ACH processing. 

At BLOCK 330. the merchant system 105 receives the report from the transaction processor 115 
detailing, for example, the results of the validation of account infonnation, the risk associated with enrolling 
the user, pemiission to enroll the user in embodiments where the transaction processor 115 acts as a 
guarantor, one or more settlement files, or the like. Upon receipt of the report, the merchant system 105 can 
advantageously determine whether to enroll the user into the transaction processing system 100. 

Based on the foregoing, the enrollment process 300 advantageously provides assurances to the 
merchant system 105 on whether the enrolling user is within an acceptable credit risk and whether the user- 
selected debit account 130 and associated banking institutions allow for electronic transactions through the 
clearinghouse system 1 25. 

Although disclosed with reference to preferred and alternative embodiments, an artisan will 
recognize from the disclosure herein that the enrollment process 300 may advantageously include portions or 
all of the forogoing functionality, without departing from the spirit or scope of aspects of the invention, 
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PURCHASE PROCESS 400 

FIGURE 4 illustrates a purchase process 400, according to an embodiment of the invention. As 
shown in FIGURE 4, the purchase process 400 generally includes the user presenting the user payment 
device 120 to the merchant receiver 140 as payment for one or more products, where ttie payment is to be 
5 debited from the debit account 130. The merchant system 105 recognizes the payment device 120, 
detennines the conesponding account information, and formats a purchase transaction request to be 
processed by the transaction processor 115. Based at least in part upon the processing by the transacbon 
processor 115, the merchant system 105 will determine whether to allow the user to purchase the one or 
more products using the payment device 120. 

1 0 The exemplary purchase process 400 begins at BLOCK 405, where the user presents his or her user 

payment device 120 to the merchant receiver 140 as payment for one or more products, where the payment 
is to be debited from the debit account 130. As disclosed in the foregoing, the presentment may be of a 
transponder, a loyalty card, a biometric, a smart card or the like, to a conesponding system designed to read 
sufficient infbnnation to uniquely locate the conBsponding account infomiatlon, such as, for example account 

IS infonnation stored in the user account database 144. At BLOCK 410, the merchant system 105 identifies the 
user payment devjce 120, accesses the relevant account infonnation, and formats a purchase transaction 
request to be processed by the transaction processor 115. 

As described in the foregoing, the fonfn and forniat of the purchase transaction request can be 
designated or defined by the merchant system 105 and/or transaction processor 115, and according to one 

20 embodiment, includes infonnation identifying the merchant, identifying the user, date and time Infonnation, 
information designating the user's account data, such as MICR data, product infonnation, amount of 
purchase, time of day, day of week, date, location of purchase, purchaser, cash back amount, type of 
payment device, and the like. The purchase transaction request may also include additional infonnation 
useful in assessing the risk of the transaction, such as, for example, a user driver's license or social security 

25 number, address, credit card data, or other demographic or financial data. 

After the transaction processor 115 processes the purchase transaction, such as, for example, 
according to various disclosed merchant-selected services, the transaction processor 115 returns an 
authorization result. According to embodiment disclosed herein, the authorization result provides an 
indication to the merchant system 105 of the risk associated with accepting the transaction. According to one 

30 embodiment when the authorization result was positive, or within predetennined acceptable ranges of risk, 
the merchant system 1 10 can finalize the purchase with the user. 

At BLOCK 420, the merchant system 105 confinns the receipt of the authorization result, and can 
further Instmct the transaction processor 115 whether the purchase was finalized between the user and the 
merchant system 105. When the purchase was finalized the merchant system 105 confinns receipt of the 
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authorization results and transmits an indication to the transaction processor 115 that the purchase was 
finalized and settlement should be processed. 

According to one embodiment, the transaction processor 115 uses the MICR conversion data from 
the MICR conversion database 156, to translate the MICR data into that infonmation desired by the 
clearinghouse system 125. The transaction processor 115 then fomnats and submits an electronic ACH debit, 
which includes the foregoing information, to the clearinghouse system 1 25. 

Based on the foregoing, the purchase process 400 advantageously advises, and often guarantees 
that the purchase transaction is within an acceptable credit risk for the merchant. Moreover, the purchase 
process 400 performs settlement processing. Although disclosed with reference to preferted and altemative 
embodiment, an artisan will recognize from the disclosure herein that the purchase process 400 may 
advantageously include portions or all of the foregoing functionality, without departing from the spirit or scope 
of aspects of the invention. 

TRANSACTION PROCESS 

FIGURE 5 illustrates a transaction processing process 500, according to an embodiment of the 
invention. As shown in FIGURE 5, the transaction processing process 500 generally includes tiie transaction 
processor 115 receiving one of an enrollment transaction request or a purchase transaction request from tiie 
merchant system 105. Based on which services ttie merchant selected, ttie transaction processing process 
500 performs various levels of risk assessment and, in some cases, may guarantee ttie transaction. Thus, 
according to one embodiment, the actions of ttie transaction processing process 500 will vary depending upon 
ttie service selections of ttie merchant. The transaction processing process 500 also can validate various 
account information and/or perfomn settlement processing tiirough communication witti the clearinghouse 
system 125. 

According to one embodiment, the transaction processing process 500 begins at BLOCK 505 where 
ttie ti^nsaction processor receives one of an enrollment transaction request or a purchase transaction request 
from ttie merchant system 105. As described in the foregoing, when ttie merchant-selected services include 
one or more of user data validation, clearance of ttie negative and positive databases, assessment of risk 
scores, or ttie like, ttie transaction processor 115 peiforms ttiose activities witti respect to ttie information 
provided in ttie particular transaction request, as illustrated in BLOCKS 510-520 of FIGURE 5. 

At BLOCK 525, the tiransaction processor 115 transmits ttie results of ttie foregoing processing back 
to the merchant system 105. As described, at BLOCK 530, the merchant system 105 confimris ttie receipt of 
ttie transaction results, and instructs ttie transaction processor 115 to validate ttie account data associated 
witti an enrollment bansaction request, settle the purchase associated witti a purchase ttansaction request, or 
ttie like. 
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When validation or settlement is desired, at BLOCK 540, the transaction processor fonnats the 
appropriate electronic ACH submissions by, for example, the conversion of ttie MICR data into infomiation 
used by the clearinghouse system 125. For example, the transaction processor 115 perfonns settlement by 
debiting the debit account 130 by an amount conesponding to the purchase transaction amount Moreover, 
5 the transaction processor 115 submits a credit of the foregoing amount, minus in one embodiment, the 
processor's fees, to the credited account 135, At BLOCK 545, the transaction processor 115 submits the 
electronic ACH debits or credits to the clearinghouse system 125. At BLOCK 550, the transaction processor 
115 reports the results back to the merchant system 105. 

As disclosed in the foregoing, the reports can advantageously Include one or more settlement files 
10 conesponding to one or more transactions or batches of transactions having been just processed or 
processed some time before. Also as disclosed, when the transaction processor 115 acts as a guarantor for 
a particular transaction, the data related to that transaction in the settlement file is often then not subject to 
reversal. 

Based on the foregoing, the transaction processing process 500 advantageously employs the 

15 clearinghouse system 125 to settle payments made using ttie payment device 120, or validate account data 
submitted at enrollment. The clearinghouse system' 125 generally performs ttie settlement purchases feister, 
more reliably, and at a significantly lower rate than ttie fixed minimum and other fees of traditional credit 
cards. In similar fashion, the transaction processing system 100 disclosed in the foregoing advantageously 
adopts many of the conveniences for users and merchants of credit card payments, without incorporating the 

20 high costs of the same. 

Although the foregoing invention has been described in tenns of certain prefened embodiments, 
other embodiments will be apparent to those of ordinary skill in the art from the disclosure herein. 
Additionally, other combinations, omissions, substitutions and modifications will be apparent to the skilled 
artisan in view of the disclosure herein. While certain embodiments of the inventions have been described, 

25 these embodiments have been presented by way of example only, and are not intended to limit the scope of 
the inventions. Indeed, the novel methods and systems described herein may be embodied in a variety of 
other fomis without departing from the spirit thereof. The accompanying claims and their equivalents are 
Intended to cover such fonns or modifications as would fall within the scope and spirit of the inventions. 

In addition to ttie foregoing disclosure, all publications, patents, and patent applications, or other 

30 references mentioned in this specification are hereiri incorporated by reference to the same extent as if each 
individual document was specifically and individually- indicated to be incorporated by reference. 
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WHATISCUIMEDIS: 

1. A financial transaction system configured to accept as payment for goods or services the 
presentation by a payor of a payment device other than a paper check, a credit card or a debit card, the 
financial transaction system comprising: 

a payment device other than a paper check, a credit card or a debit card, where 
presentation of the payment device for goods or services indicates that funds are to be drawn on a 
checking account of a payor to pay for the goods or services in an electronic transaction; 

a point of sale device which receives from the payment device, identification data useable 
to uniquely identify the payment device; and 

one of more computing devices that assess risk wherein the one or more computing 
devices assess the risk of the electronic transaction, and accept or decline the payment for the 
goods and services. 

2. The financial transaction system of Claim 1, wherein the payment device comprises a 
transponder. 

3. The financial transaction system of Claim 1, wherein the payment device comprises one or 
more loyalty cards. 

4. The financial transaction system of Claim 1 , wherein the payment device comprises one or 
more smart cards. 

5. The financial transaction system: of Claim 1, wherein the payment device comprises a 
computing device. 

6. The financial transaction system of Claim 5, wherein the payment device comprises a 
personal digital assistant. 

7. The financial transaction system of Claim 1, wherein the payment device comprises a 
mobile telephone. 

8. The financial transaction system of Claim 1, wherein the payment device comprises one or 
more biometric elements. 

9. The financial transaction system of Claim 1, wherein the payment device comprises one or 
more devices storing or using biometric data. 

10. The financial transaction system of Claim 1, wherein the point of sale device comprises a 
wireless receiver. 

11. The financial transaction system of Claim 1 , wherein the point of sale device comprises a 
magnetic strip reader. 
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12. The financial transaction system of Claim 1, wherein the one or more computing devices 
Include gateway computing devices which allow secondary merchants to accept presentation of the payment 
device for goods and services. 

13. The financial transaction system of Claim 1. wherein the electronic transaction includes an 
S enrollment transaction designed to detennine whether the payor meets predetenmined criteria set by the 

financial transaction system. 

14. The financial transaction system of Claim 1. wherein the one or more computing devices 
receive results from a transaction processing system. . 

15. The financial transaction system of Claim 14, wherein the results include an authorization to 
1 0 accept the presentation of the payment device as payment for the goods or services. 

1 6. The financial transaction system of Claim 14, wherein the results include an authorization to 
enroll the payor with the financial transaction system by providing the payor with the payment device. 

17. The financial transaction system of Claim 1 wherein the one or more computing devices 
comprise: 

1 5 a server system including a merchant receiver configured to recognize the payment device 

presented by the user as payment for goods or services; and 

one or more databases storing MICR data used to Identify the checking account. 

1 8. The financial transaction system of Claim 1 further comprising: 

Identification infomiation conversion data usable to convert the Identification data into 
20 Information used by a clearinghouse system to perfomi electronic check processing; and 

historical transaction data usable to assess the risk of performing the electronk: transaction. 

19. The financial transaction system of Claim 1. wherein the one or more computing devices 
perform settlement processing. 

20. The financial transaction system of Claim 1, wherein the one or more computing devices 
25 perfonm validation processing. 

21. A method of accepting a payment device as payment for goods or services, the method 

comprising: 

receiving identification infomfiation from a payment device presented by a user for payment 
of goods or services, wherein the payment device is not a paper check, a credit card, or a debit card; 
30 detenmining checking account data associated with the payment device wherein 

presentation of the payment device indicates that funds are to be drawn on a checking account of 
the user; 

initiating an electronic transaction using the checking account data; 
obtaining an assessment of a risk of the electronic transaction; and 
35 accepting or declining the payment for the goods or services. 
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22. The method of Claim 21. further comprising enrolling the user by Issuing the payment 
device and obtaining the checking account data. 

23. The method of Claim 22, further comprising obtaining an assessment of a risic of enrolling 

the user. 

24. The method of Claim 22 further comprising acquiring infomiation identifying the user 
attempting to enroll into a system providing for the payment goods or sen/ices from the checking account of 
the user through the presentation of the payment device. 

25. The method of Claim 24. wherein the information includes infonnation found on the user's 
driver's license. 

26. The method of Claim 24, wherein the infomiation includes demographic infomiation. 

27. The method of Claim 24 wherein the infonnation includes biometric information. 

28. The method of Claim 24, wherein the infonnation includes password information. 

29. The method of Claim 21, wherein the assessment of the risk is acquired through a 
transaction processor. 

30. The method of Claim 21 wherein obtaining the assessment of risk is based on one or more 
characteristics of the electronic transaction 

31 . The method of Claim 30 wherein the checking account infomiation comprises MICR data. 

32. The method of Claim 31. wherein the one or more characteristics of the electronic 
transaction include whether the MICR data is valid. 

33. The method of Claim 31, wherein the MICR data is valid when it can be converted Into 
infonnation used by clearinghouse systems to transfer funds. 

34. The method of Claim 30, wherein the one or more characteristics of the electronic 
transaction include whether an assessed risk of the electronic transaction is within predetemiined parameters. 

35. The method of Claim 34, wherein the assessed risk includes an evaluation of historical 
transaction infonnation. 

36. The method of Claim 35, wherein the historical transaction infonnation Includes negative 
transaction infonnation. 

37. The method of Claim 35, wherein the historical transaction Infomiation includes positive 
transaction infonnation. 

38. The method of Claim 30. wherein the one or more characteristics of the electronic 
transaction include whether the electronic transaction will be guaranteed. 

39. The method of Claim 21 , further comprising transmitting MICR data to a gateway system. 

40. The method of Claim 21, further comprising transmitting infonnation to a gateway system, 
and wherein the gateway system detennines whether to accept or decline the electronic transaction. 

41 . The method of Claim 21 , wherein the payment device comprises a transponder. 
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